home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
STUTTGART
/
UTIL
/
FILEUTIL
/
HIERARCH
/
!Hierarchy
/
doc
/
dTransProt
next >
Wrap
Text File
|
1995-01-17
|
9KB
|
235 lines
---------------------------------------------------------------------
Format eines User Message Blocks (R0 = 17-19)
---------------------------------------------------------------------
Entry:
R1 + 0 Blockgröße, 20-256 Bytes (word-aligned)
R1 + 4 vor Ausführung von Wimp_SendMessage unbenutzt
R1 + 8 vor Ausführung von Wimp_SendMessage unbenutzt
R1 + 12 your_ref (0, wenn die Nachricht original, also keine
Antwort ist)
R1 + 16 message action (z.B. Message_DataSave = 1)
R1 + 20 message data (Inhalt hängt von message action ab)
...
Exit:
R1 + 4 Task Handle des Absenders
R1 + 8 my_ref (einmaliger von Wimp generierter Wert >= 0)
---------------------------------------------------------------------
Message_DataSave
---------------------------------------------------------------------
...
R1 + 20 Window Handle
R1 + 24 Icon Handle
R1 + 28 Maus-X-Koordinate (absolut)
R1 + 28 Maus-Y-Koordinate (absolut)
R1 + 36 geschätzte Anzahl der zu übertragenden Daten
in Bytes
R1 + 40 Typ der zu übertragenden Daten / Datei
R1 + 44 vorgesehener Dateiendname (leafname) der
Daten (+ 0-Terminator)
Die ersten vier Werte stammen von Wimp_GetPointerInfo. Der
Rest muß vom Programm eingesetzt werden. Ist noch nicht bekannt,
wie groß eine Datei ist, sollte man anfangen zu überlegen, wie
groß die Datei mindestens sein wird.
Zusätzlich zu den üblichen dreistelligen Hexadezimalzahlen sind
folgende Werte für die Benutzung im Data Transfer Protocol
definiert worden:
&1000 Verzeichnis
&2000 Applikationsverzeichnis
&FFFFFFFF Typenlose Datei (mit Load/Exec Address)
---------------------------------------------------------------------
Message_DataSaveAck
---------------------------------------------------------------------
...
R1 + 12 your_ref = my_ref der vorausgegangen Message_DataSave
...
R1 + 20 Window Handle
R1 + 24 Icon Handle
R1 + 28 Maus-X-Koordinate (absolut)
R1 + 28 Maus-Y-Koordinate (absolut)
R1 + 36 geschätzte Anzahl der zu übertragenden Daten
in Bytes (-1, falls die Datei 'unsave' ist)
R1 + 40 Typ der zu übertragenden Daten / Datei
R1 + 44 kompletter Pfadname der Datei oder <Wimp$Scrap>
(+ 0-Terminator)
Die Werte von R1 + 20 bis R1 + 32 stammen aus der vorangegangen
Message_DataSave <DateiEndName>. Ist der Empfänger der Daten
- also der Absender dieser Message_DataSaveAck - kein Filer,
dann hat er bei R1 + 36 (Dateigröße in Bytes) -1 einzusetzen.
Dies zeigt der übertragenden Applikation, daß die Daten nicht
gesichert werden, also nicht in einer permanenten Datei landen.
Der Filer setzt bei R1 + 36 natürlich nicht -1 ein und gibt ab
R1 + 44 den kompletten Pfadnamen der zu erzeugenden Datei an.
---------------------------------------------------------------------
Message_DataLoad
---------------------------------------------------------------------
...
R1 + 12 your_ref = my_ref der vorausgegangenen
Message_DataSaveAck
...
R1 + 20 Window Handle
R1 + 24 Icon Handle
R1 + 28 Maus-X-Koordinate (absolut)
R1 + 28 Maus-Y-Koordinate (absolut)
R1 + 36 geschätzte Anzahl der Daten in Bytes
R1 + 40 Typ der Daten / Datei
R1 + 44 voller Pfadname der Datei oder <Wimp$Scrap>
(+ 0-Terminator)
Der Empfänger dieser Message_DataLoad sollte den Datei-Typ
prüfen und je nach Wert die Datei laden. War der Ladevorgang
erfolgreich, dann sollte der Empfänger mit Message_DataLoadAck
antworten.
Was zu beachten ist: bei R1+36 sollte die Größe der zu ladenden
Datei wenn möglich genau angegeben werden. Ich habe den (vermutlich)
typischen Fehler gemacht und den Message-Block der vorausgehenden
Message_DataSaveAck größtenteils unverändert übernommen. Das Problem
zeigte sich allerdings erst nach einem Update von !Zap auf Version
1.20, das sich weigert, eine Datei zu laden, die -1 Bytes groß ist.
Bekommt der Absender dieser Message_DataLoad keine Bestätigung
in Form von Message_DataLoadAck, dann sollte er die Datei
<Wimp$Scrap> löschen und folgenden Fehler ausgeben:
'Data transfer failed: Receiver died'
---------------------------------------------------------------------
Message_DataLoadAck
---------------------------------------------------------------------
...
R1 + 12 your_ref = my_ref der vorausgegangenen Message_DataLoad
...
R1 + 20 Window Handle
R1 + 24 Icon Handle
R1 + 28 Maus-X-Koordinate (absolut)
R1 + 28 Maus-Y-Koordinate (absolut)
R1 + 36 geschätzte Anzahl der Daten in Bytes
R1 + 40 Typ der Daten / Datei
R1 + 44 voller Pfadname der Datei oder <Wimp$Scrap>
(+ 0-Terminator)
Der Absender dieser Message_DataLoadAck braucht effektiv nur den
Typ der Message (bei R1 + 16) auf 4 = Message_DataLoadAck setzen
und bei R1 + 12 (your_ref) den Wert von R1 + 8 (my_ref) einsetzen.
Der Empfänger dieser Message ist der Absender der vorausgegange-
nen Message_DataLoad.
---------------------------------------------------------------------
Message_DataOpen
---------------------------------------------------------------------
...
R1 + 20 Window Handle des Verzeichnisfensters in dem die
angeklickte Datei liegt.
R1 + 24 unbenutzt
R1 + 28 absolute x-Koordinate des Datei-Icons
R1 + 32 absolute y-Koordinate des Datei-Icons
R1 + 36 0
R1 + 40 Typ der Datei
R1 + 44 voller Pfadname der Datei (+ 0-Terminator)
Die Koordinaten des Icons können benutzt werden, um ein
klein wenig Mac- bzw. Atari-Feeling auf den Archimedes zu
bringen, indem man eine 'Zoom-Box' von den Koordinaten des
Icons bis zum neu zu öffnenden Fenster mit dem Inhalt der
Datei animiert. (Hat das schon mal jemand auf dem Archi
gesehen? Braucht man das?)
Diese Message wird vom Filer an alle aktiven Applikationen
verschickt, wenn der Benutzer eine Datei per Doppelklick
öffnen will. Message_DataOpen wird immer als Broadcast-
Message verschickt.
Bestätigt wird diese Message mit Message_DataLoadAck. Dies
muß auf jeden Fall vor dem nächsten Aufruf von Wimp_Poll
geschehen. Es ist also sinnvoll, erst die Message des
Filers zu bestätigen und dann die Datei zu laden.
---------------------------------------------------------------------
Message_RAMFetch
---------------------------------------------------------------------
R1 + 12 your_ref = my_ref der vorausgegangenen
Message_DataSave / Message_RAMTransmit
...
R1 + 20 Addresse des Übertragungsbuffers
R1 + 24 Größe des Buffers in Bytes
Wird als User_Message_Recorded gesendet, damit bei einem
Ausbleiben der Bestätigung auf das 'alte' Protokoll zu-
rückgegriffen wird bzw. eine bereits eingeleitete Übertra-
gung abgebrochen werden kann.
Tritt der letzte Fall ein, so erzeugt das übertragende
Programm eine Fehlermeldung. Der Empfänger meldet einen
Fehler, wenn es die übertragenen Daten nicht verarbeiten
kann (z.B. wegen Speichermangel). Es sollten dann auch
keine Message_RAMFetch mehr gesendet werden.
Die empfangende Applikation kann sich bei der Einrichtung
des Buffers nach der geschätzten Größe der zu übertragenden
Datei richten, sollte aber darauf vorbereit sein, mehr
Daten zu empfangen.
---------------------------------------------------------------------
Message_RAMTransmit
---------------------------------------------------------------------
R1 + 12 your_ref = my_ref der vorausgegangenen
Message_DataSave / Message_RAMTransmit
...
R1 + 20 Addresse des Übertragungsbuffers
R1 + 24 Anzahl der in den Buffer geschriebenen Bytes
Die übertragende Applikation sendet Message_RAMTransmit als
Antwort auf Message_RAMFetch. Wenn die Anzahl der übertragenen
Bytes kleiner als der eingerichtete Buffer ist, dann ist dies
die letzte Message dieses Typs, ansonsten gibt es noch Daten
zu übertragen und der Empfänger wird eine weitere Message
vom Typ Message_RAMFetch senden. (siehe 'doc.General', Zeilen
275ff)
Alle Message_RAMTransmit sollten als User_Message_Recorded
gesendet werden. Wird keine Bestätigung von der empfangenden
Applikation (Message_RAMFetch) gegeben, sollte der Datentransfer
von der übertragenden Applikation abgebrochen werden, indem
kein weiteres Message_RAMTransmit erfolgt. Es liegt ebenfalls
an der übertragenden Applikation, gegebenenfalls eine Fehler-
meldung auszugeben.
Die letzte Nachricht dieses Typs sollte als User_Message
gesendet werden, da der Empfänger keine weitere Message_RAMFetch
als Bestätigung senden wird. Beachten Sie, daß die letzte
Message_RAMTransmit auch gleichzeitig die erste und einzige
Message dieses Typs sein kann, wenn der Übertragungsbuffer
groß genug ist.